I want to include kubernetes/enhancements#5491 if it's worth putting in the feature blog.

ref: docs PR is #54561

Sorry I forgot this one, it is definitely worth including. Added your suggestion.

Similar to my comment on #54567 (comment), do you think we could make it a bit more focused on just the benefits of the feature and leave some of the details to the DRA documentation? And see if we can keep it to a single paragraph?

@everpeace Could you take a look at updating the description to align a bit more with the other features, ref my previous comment?

It's in now, right?

I want to include kubernetes/enhancements#4680 in the feature blog.

ref: docs PR is #54420

So I've added your proposal for now, but do you think we can shorten it a bit and make it just one paragraph? There is a large number of features and we don't want the blog post to be too long. Focus just on the benefits of this feature and what it enables and leave the details to the DRA docs which we link to. Also, including that it is graduating to beta in 1.36 is already given from the context.

Sorry I forgot to add this in the first draft, it is of course something we should include in the blog.

@harche Could you take a look at this? Currently the description of this feature gets into quite a bit more detail than the other descriptions and I think some of it can be left to the documentation.

thanks @mortent , does this look better ?#54567 (comment)

Calling those out seems reasonable for a blog post because this is newsworthy.

We could link to https://github.com/kubernetes-sigs/wg-device-management/tree/main/device-ecosystem but I'll defer to SIG Docs about that.

You can link to https://www.kubernetes.dev/community/community-groups/wg/device-management/

If we want to publish something like https://github.com/kubernetes-sigs/wg-device-management/tree/main/device-ecosystem for end users, we can. Maybe a (separate)
blog article?

It's not a good fit for the official Kubernetes documentation; it has a bit too much about vendors and offerings. But a neutral blog article could be OK.

Should this be called "Node Allocatable Resources" instead of "Native Resources"?

cc @pravk03

I think I used the name from the KEP, but I see that #54598 uses the term node allocatable resources. @pravk03 I assume node allocatable resources is the preferred name here? And do we spell that with a hyphen or not (the docs seems inconsistent on this)?

Yes, we have renamed this to node allocatable resources.

Following the convention in the Node Allocatable and Resource Management documentation, we can omit the hyphen. I’ll update the the KEP and docs to keep it consistent.

Operators here mean DevOps? I am wondering if we need to highlight that this is only a consumption API. All the management and monitoring must be done differently with DRA.

Section has been updated.

slight rephrase of "not forced to" to something like "continue using familiar API while exploring all the benefits of a new API" would be better.

I've rewritten this section a bit. Let me know if you think it looks better now.

I think the key here is that it is dynamic, while safe and efficient. So the partitioning can dynamically change based on workload demands

Agree. I've reworked the section a little bit.

should we say that the big priority is to migrate community to DRA? And also make it a call to action?

Good point. I've added a small section for this.

kubernetes/enhancements#5304

This enhancement was add in 1.36, I wonder if this section should contain a sub-section for it.

cc @pohly

Let's add it. Can you suggest something?

Sure, added a suggestion here: https://github.com/kubernetes/website/pull/54567/changes#r3076822230

I recommend writing the graduation as if it was in the past (which it will be). Also, watch out for implying that beta → enabled by default. Some things go to beta as initially opt-in.

I would use an actual heading here; also, use sentence case, eg

### Prioritized list (stable) {#prioritized-list}

and similarly for other headings

Idiomatically, don't use title case for the names of features. Outside of a hyperlink we use italics; within a hyperlink they are optional.

(for this article, only a nit)

Remember that this is a post release blog:

I recommend writing the graduation as if it was in the past (which it will be). Also, watch out for implying that beta → enabled by default. Some things go to beta as initially opt-in.

Try to describe what is possible (rather than summarizing the enhancement).

eg

People using Kubernetes in their platform may have large AI/ML workloads
and rely on strict _topological scheduling_ (matching Pods to run across multiple nodes
with firm constraints, such as making an entire rack of compute available
along with interconnects).
DRA provides an [integration](/docs/concepts/scheduling-eviction/dynamic-resource-allocation/#workload-resourceclaims)
with the Workload API, so that you can get near seamless management of
infrastructure resources, even across very large sets of Pods.

By associating ResourceClaims or ResourceClaimTemplates with the PodGroup API
(also new in Kubernetes v1.35),
this integration eliminates previous scaling bottlenecks, such as the limit on the
number of Pods that can share a claim, and
removes the burden of custom or manual claim
management from specialized orchestrators.

Notice how I didn't mention the feature other than by hyperlinking to its docs. I would consider also mentioning the feature gate on this one.

If "we" means "all the contributors to DRA" then it's best not to have it also mean "anyone using Kubernetes", within one article.

This link is stale, and the transfer happened before the v1.36 release. Let's update and switch to past tense.

Watch out for "now"; was this not possible in v1.35?

If it was, even behind a feature gate, we should reword.

?